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Systems  of  Systems:  4  Types  defined  by  OSD  SE 
Guide  for  Systems  of  Systems 


*  Player  =  participant  in  £ 
collaboration 


central  management  authority  and 
centrally  agreed  upon  purpose? 

Yes 


component  systems  interact  voluntarily 
to  fulfill  agreed  upon  central  purposes? 


Virtual:  Large-scale  behavior  emerges — and  may 
be  desirable — but  this  type  of  SoS  must  rely  upon 
relatively  invisible  mechanisms  to  maintain  it. 


component  systems  retain  independent 
ownership,  objectives,  funding, 
development  and  sustainment  approaches? 


Collaborative:  The  central  players 
collectively  provide  some  means  of 
enforcing  and  maintaining  standards. 


Relatively  few 
J  dominant 
\  players*  v 


Directed:  the  integrated  system-of-systems  is 
built  and  managed  to  fulfill  the  specific  centrally 
managed  purposes  of  its  owners 


Acknowledged:  changes  in  the  (component) 
systems  are  based  on  collaboration  between  the 
SoS  and  the  (component)  system(s) 


Source  of  definitions:  Systems  Engineering  Guide  for  Systems  of  Systems,  OSD,  Version  1.0  August  2008.  Brackets  added. 
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Architectural  Genres: 

different  genres  for  different  purposes 

The  primary  interfaces  across  genres  as  evidenced  by  working  group 
discussions: 


The  enterprise  is 
supported  by  an 
infrastructure 


Enterprise  Architecture 


System  architecture 


Software 
architect  mostly  on 
the  receiving  end 


Software  architecture 


These  genres  reflect  a  supply-side  perspective  on  the  enterprise 


Source:  U.S.  Army  Workshop  on  Exploring  Enterprise,  System  of  Systems,  System,  and  Software  Architectures,  John  Bergey,  Stephen  Blanchette,  Jr.,  Paul  Clements,  Mike  Gagliardi, 
John  Klein,  Rob  Wojcik,  Bill  Wood,  March  2009  TECHNICAL  REPORT  CMU/SEI-2009-TR-008 
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The  Enterprise  Architecture  defines  the  way  it 
creates  value:  Zachman  roots  to  DODAF 


Source  of  coloured  squares:  Zachman  Framework,  www.zifa. 
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Speech  by  Secretary  Gates: 

There  are  two  paradigms  that  must  coexist 

The  need  for  state  of  the  art  systems  -  particularly  longer  range  capabilities  - 
will  never  go  away... 

We  also  need  specialized,  often  relatively  low-tech  equipment  for  stability  and 
counter-insurgency  missions. 

•  How  do  we  institutionalize  rapid  procurement  and  fielding  of  such 
capabilities? 

•  Why  do  we  currently  have  to  go  outside  the  normal  bureaucratic  process? 

Our  conventional  modernization  programs  seek  a  99%  solution  in  years. 

Stability  and  counter-insurgency  missions  require  75%  solutions  in 
months. 

•  The  challenge  is  whether  in  our  bureaucracy  and  in  our  minds  these  two 
different  paradigms  can  be  made  to  coexist. 


Extracted  from  speech  delivered  by  Secretary  of  Defense  Robert  M.  Gates, 

National  Defense  University,  Washington,  D.C.  September  29,  2008  http://www.defenseiink.mii/speeches/ 

speech. aspx?speechid=  1 279 
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The  three  tempos:  analyzing  the  impact  of  the 
enterprise’s  relation  to  customers’  changing  demands 


Supplier 

The  supplier  responds  to  the 
client  enterprise  aligning  to 
the  demand  of  the  customer 


Client  (defense) 
Enterprise 

The  client  enterprise  aligns  to 
the  demand/threat  of  the 
customer 


Customers  of  the 
Client  Enterprise 


The  customer's 
demand/threat 


<3 
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Acquisition 
•  Tempo 
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rods  Tempo 


r 


1 


The  rate  at  which 
new  requirements 
can  be  met 


The  rate  at  which  the  defense  The  rate  at  which  new  forms 
enterprise  is  able  to  support  new  of  demand/threat  need  to 
forms  of  mission  capability  be  satisfactorily  addressed 
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Managing  diverging  tempos:  the  readiness  tempo 
has  to  be  managed  in  its  own  right 


The  two  paradigms  are  about  diverging  acquisition  and  demand/threat 
tempos 

•  Their  coexistence  depends  on  managing  the  readiness  tempo  in  its  own  right 
Managing  the  readiness  tempo  means: 

•  sustaining  multiple  collaborations  between  players  able  to  address  concurrent 
types  of  demand/threat 

•  building  organizational  agility  into  the  supporting  socio-technical 
infrastructures 
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Governance  of  a  Collaborative  SoS:  involves 
multiple  collaborations  with  a  supporting  infrastructure 

The  players  in  a  collaboration  can  be  spread  across  multiple  enterprises  and/or 
different  parts  of  a  single  enterprise 


Larger  stakeholder  context 
Collaborations  of  Players 


Supporting  Infrastructure 


V 


Multiple  value- 

creating 

relationships 


Governance 


It  is  the  players  participating  in  a  particular  collaboration  who  will  define 

•  Their  system-of-interest  and  its  environment 

•  The  stakeholders  they  judge  to  be  relevant 

•  The  way  they  want  their  collaboration  supported  by  the  infrastructure 
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And  SO...  a  demand-side  perspective  needs  to  be  added 


Collaborative  SoS  present  a  different  order  of  complexity 


This  complexity  arises  because 

•  multiple  collaborations  between  players  exist  concurrently, 

•  each  with  its  own  relationship  to  demand/threat,  and 

•  supported  by  a  shared  infrastructure 


It  means  adding  a  demand-side  perspective  on  the  collaborations 
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Managing  both  paradigms:  means  managing  the 
relationship  between  the  two  ‘V’s 


...  constrains  what  is 
Effects  on  Demand/Threat  possible  up  here 

M.  . 

Scenarios  Threat  Mission 
Tempo  Command 

S 


Requirement 


Design 

decomposition 


Acquisition 
•  Tempo 


System  components 

Boxer,  P.J.  (2007)  Managing  the  SoS  Value  Cycle,  January  2007,  http://www.asymmetricdesign.com/archives/85 


What  happens  down 
here... 
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The  demand-side  perspective:  creates  gaps  in  Zachman 


MOTIVATION 

(WHY) 
e.g.  strategy 


Source  of  gaps:  Philip  Boxer,  Modeling  structure-determining  processes.  htto://www.  asvmmetricdesian.  com/archives/59.  December  2006 
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DODAF  2.0  Entities  and  Views: 

what  gets  modeled? 


DO  DAF  TAXO  NOMY  TYPES  and  C  ADM 

2.0  PRINCIPAL  INDEPENDENT  ENTITIES 

(AV) 

1  (2) 

Operati  onal  View 
(OV) 

1  12}  (3)  (4)  (5}  (6}  {7} 

System  View 
(SV) 

{1}  {2}  {3}  {4}  {5}  {6}  {7}  {8}  {10}  {11} 

Tech 

View(TV) 

(«  a 

Opeiati  onal  Nodes 

Organizati  ons,  lypesof  Organized  ons,and 

Performance  Att  ributes 

Technical  Standa  ids 

info  Processing,  Info  Tra  nsfer,  Data,  securi  iy, 
and  Human  Factors 

a  ' 

©  ' 

a  ' 

B . 

H  z  Z  Z 

H  z 

Z  Z  Z  Z 

Z  Z  Z  Z  Z  Z  Z 

1  1 

Tech  no  logy  Areas 

Physical  Nodes 

Faciliti  es,  Pta  tf  orms,  Units, andLocati  ons 

Triggers/Events 

Opeiati  onalActi  viti  es 

(and  Tasks) 

©  ' 

a  " 
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111  1111 
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1  1 

Tech  no  logy  Areas 

Familiesrof-  Systems,  Systems-of-  Systems, 
Networks,  Applicati  ons,  Soft  ware,  and 
Equipment 

Informati  on  Elements 

System  Functi  ons 

a  ' 
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a  " 
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z  - 

■  '  z  z  z  z  ' 
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z  z 
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Modeling 

Elements 


Accountability 

Hierarchy 


Unit  of 

Accountability 


Physical  structure 
&  behavior 


Physical 

Structure 


A  Physical 
Event 


Physical 

Process 


System  structure 
&  behavior 


XD: 


System 

Structure 


=  Taxonomyelement  plays  a  primary  role  Z  =  element  plays  a  secondary  role  11  =  unstructured  text  or  graphics 

Source:  Fig  3-2,  DoD  Architectural  Framework  version  2.0  Volume  III:  Architecture  Data  Description,  DOD  Architecture  Framework  Working  Group,  J 


A  Digital 
Trace 

Digital 
Process 
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Entities  not  modeled  by  DODAF  2.0: 

the  demand-side  perspective  is  not  included 


Accountability 

Hierarchy 


□ 


Unit  of 

Accountability 


The  relationships  to  these  entities  are  not  dealt  with 
DODAF  2.0  models 


Physical  structure 
&  behavior 


Synchronization  across 
Accountability  Hierarchies 


□  Physical 
Structure 


Dynamic  configuration  K.  Socio-technical 

of  physical  structure  1 - Synchronization 


A  Physical 
Event 

□  Physical 
Process 


V  Outcome  from  complex 
chains  of  events 


System  structure 
&  behavior 


□  System 
structure 

A  Digital 
Trace 


Dynamic  configuration 
of  system  structure 


Digital  Synchronization/ 
Data  Fusion 


The  Organization 
of  Demand 
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Problem 

Domain 


Demand 

Situation 
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Customer 

Situation 


Demand 

Driver 
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Describing  the  demand-side:  bridging 
the  gaps 


Source  of  gaps:  Philip  Boxer,  Modeling  structure-determining  processes.  http://www.  asvmmetricdesign.  com/archives/59.  December  2006 
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Summary:  both  supply-side  and  demand-side 
perspectives  need  to  be  modeled 

Supporting  the  development  of  collaborative  systems  of  systems 
involves  modeling  more  than  the  supply-side  entities  in  Zachman-rooted 
representations  like  DODAF  2.0 

•  Including  a  demand-side  perspective  means  being  able  to  account  for 
-cross-cutting  synchronization,  not  just  hierarchical  accountability 

-  multi-enterprise  development  and  co-evolution 

-  inherent  variation  in  the  way  user’s  demands  emerge  and  evolve 

-  the  resultant  tempo  of  the  ongoing  development  of  systems  of  systems 
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If  you’re  a  software  architect... so  what? 

If  you  think/know  you’re  involved  in  a  SoS  collaboration, 

•  It  is  likely  that  the  requirements  you  are  working  to  do  NOT  account  for 
sufficient  demand-side  variety 

-  Don’t  over-constrain  your  software  architecture  too  early 

-  Look  for  architectural  mechanisms  that  can  accommodate  later  information  on 
interfaces  and  implementations 

•  Try  to  find  out  the  level  of  awareness  of  SoS  issues  that  is  present  on  the  part 
of  your  systems  engineers 

-  The  more  they  are  aware  of  their  lack  of  control  over  organizational  and  technical 
interactions  across  the  collaboration,  the  less  likely  they  will  be  to  pass  down  over¬ 
constraining  architecture  requirements  to  the  software 

-  If  awareness  of  SoS  issues  is  low,  find  out  how  they  are  planning  to  deal  with  some 
of  the  demand-side  constructs  discussed  here 

•  Start  thinking  about  your  customers’  “operations  architecture”  -  the 
components  and  interfaces  that  they  are  operating  with  and  that  you  are 
supporting  with  your  software 

-  Look  for  points  of  complementarity  and  conflict  between  your  software  architecture 
and  your  customer’s  “operations  architecture” 
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